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FOREWORD 

(This foreword is not part of this standard.) 


This document has been submitted to APCO/NASTD/FED by the 
Telecommunications Industry Association (TIA), as provided for in a Memorandum 
of Understanding (MOU) dated December, 1993. That MOU provides that 
APCO/NASTD/FED will devise a Common System Standard for digital public safety 
communications (the Standard), and that TIA shall provide technical assistance in 
the development of documentation for the Standard. This document has been 
developed by TR8.19 (Wireline Interfaces) with inputs from the APCO Project 25 
Interface Committee (APIC), the APIC Fixed Station Interface Task Group, and TIA 
Industry members. This document is being published to provide technical 
information on the emerging digital techniques for Land Mobile Radio Service. 


This document defines a Conventional Fixed Station Interface (CFSI) for Project 25. 
The CFSI is the interface between a conventional fixed station, which is defined in 
this document as a functional component of a Fixed Station Subsystem, and a 
Conventional Fixed Station Host (CFSH). A CFSH is defined in this document as a 
functional component of either an RF Subsystem (RFSS) or a Console Subsystem. 
For the purposes of this document the CFSI is defined as a specialization of the 
generic Project 25 Fixed Station Interface (FSI) described in TSB-102-A. Future 
related standardization efforts are planned to develop new TIA standards defining 
protocols for a Trunked Fixed Station Interface for Project 25. In addition, future 
associated standardization efforts are planned to develop new TIA standards 
defining compliance tests (e.g., measurement methods, performance 
recommendations, and interoperability tests) for the Project 25 Fixed Station 
Interface protocols defined in this and future related standards. 
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The reader’s attention is called to the possibility that compliance with this document 
may require the use of one or more inventions covered by patent rights. 

By publication of this document, no position is taken with respect to the validity of 
those claims or any patent rights in connection therewith. The patent holders so far 
identified have, we believe, filed statements of willingness to grant licenses under 
those rights on reasonable and nondiscriminatory terms and conditions to applicants 
desiring to obtain such licenses. 
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TIA intellectual property rights policy: 

No patents have been identified. 

TIA shall not be responsible for identifying patents for which licenses may be 
required by this document of for conducting inquiries into the legal validity or scope 
of those patents that are brought to its attention. TIA will neither be a party to 
discussion of any licensing terms or conditions, which are left to the parties involved, 
nor will TIA opine or judge whether proposed licensing terms or conditions are 
reasonable or non-discriminatory. 
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1 Scope 

This document defines a Conventional Fixed Station Interface (CFSI). The CFSI is 
the interface between a conventional fixed station, which is defined in this document 
as a functional component of a Fixed Station Subsystem, and a Conventional Fixed 
Station Host (CFSH). A CFSH is defined in this document as a functional component 
of either an RF Subsystem (RFSS) or a Console Subsystem. 1 Clause 6 describes 
these elements and their relationship to each other. For the purposes of this scope 
statement, a fixed station may be either an “analog fixed station” or a “digital fixed 
station”. An “analog fixed station” supports conventional FM RF resources or their 
equivalent. A “digital fixed station” supports the P25 Common Air Interface (CAI) for 
P25 conventional systems (see [8]). 

This document fully describes the CFSI including its architecture (clause 6), and 
protocols (clauses 7 and 8). Clause 7 describes a basic analog audio and control 
interface, while clause 8 describes a more capable Internet Protocol (IP) (see [1]) 
based digital interface. This interface has been designed to work with IPv4. Use of 
this interface with IPv6 is for further study. 

The functional scope of the CFSI as described herein comprises the following CFSI 
Analog and CFSI Digital Interface provisions. 

The CFSI Analog Interface provides: 

1. Transport of clear audio between a fixed station and its host 2 providing 
capabilities for full-duplex, half-duplex and simplex communications at the 
discretion of the fixed station. 

2. Transport of E&M control signaling between a fixed station and its host to 
provide a simple “Push-to-talk” and “COR” capability. 

3. Transport of Tone Remote Control (TRC) control signaling from a host to a 
fixed station to provide a variety of control functions including transmit 
channel control, squelch control, monitor control, clear/secure controls, 
analog/digital mode controls, etc. 

4. A primitive “Intercom” capability allowing for the transport of audio between 
the fixed station and its host without initiating an RF transmission. 


1 For the purposes of this document the CFSI is defined as a specialization of the generic Project 25 
Fixed Station Interface (FSI) described in TSB102-A (see [19]). 

2 Throughout this document the terms “Host” or “host” refer to the CFSH as defined in this document. 
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The CFSI Digital Interface provides: 

1. IP based capabilities equivalent to those provided via the Analog Interface. 

2. Transport of encrypted audio between a digital fixed station and its host. 

3. Transport of Caller-ID information between a digital fixed station and its 
host. This includes Unit ID from field units to consoles, and “Console ID” 
from consoles to field units. 

4. Transport of Talk-group information between a digital fixed station and its 
host. 

5. Transport of NAC code information between a digital fixed station and its 
host. 

6. Transport of Emergency Alert messages from the digital fixed station to its 
host. 

7. Transport of Emergency indications along with the voice stream between 
the digital fixed station and its host. 

8. Transport of Received voter identification from the digital fixed station to its 
host. 

9. Advanced Control of the Fixed Station by its host including the disabling of 
all squelch (monitor function). 

10. A standard option to transport intercom audio to and from the fixed station 
location. 


2 




TIA-102.BAHA 


2 Document Organization 

This document defines the Conventional Fixed Station Interface (CFSI) for Project 
25 systems. 

The document is organized into eight clauses that are structured as follows: 

• Clause 1 provides a general description of the CFSI, including identification of 
key user requirements; 

• Clause 2 identifies the document organization and structure; 

• Clause 3 identifies the normative and informative references; 

• Clause 4 defines key terms; 

• Clause 5 provides a list of acronyms and abbreviations; 

• Clause 6 defines the CFSI architecture; 

• Clause 7 defines the CFSI analog interface; 

• Clause 8 defines the CFSI digital interface. 


3 
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3 References 
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indicated were valid. All standards are subject to revision, and parties to agreements 
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4 Definitions 

Base Station.Equipment within a fixed station subsystem that 

performs at least the Base Radio functions of 
power amplifier (PA), RF front-end, modulation 
and demodulation. It may perform other fixed 
station subsystem functions also. It is normally 
connected to a console or RFSS through a Fixed 
Station Interface. 

Block Payload.The actual data contained in the block. The block 

data may be voice, control words, low speed data, 
etc. 

Block Payload, Type Block PT.A number which describes the basic payload type 

as defined by the IETF (when E bit is set to 0) or, it 
may be a profile specific type (when E bit is set to 
1). In this specification, E = 1. 

Block Type.A block identifier used to indicate what type of 

data is contained in the block, such as CAI voice, 
IMBE only, link control word, encryption sync 
word, etc. 

CAI (Common Air Interface) .A radio to radio signal path defined in terms of 

access method, modulation scheme, vocoding 
method, channel data rate, and channel data 
format. 

Console.A device used by a dispatcher to communicate 

with radios in the field. These range from simple 
devices that resemble telephones to advanced 
touch screen computer based systems that control 
multiple transmitters and can patch multiple call 
groups together. 


Fixed Data Network.A network of fixed computer equipment for wide- 

area data communications. 

Fixed Station.RF equipment which is generally in a fixed 


location. It transmits the outbound path of the 
common air interface and receives the inbound 
path of the common air interface. It may also 
transmit or receive conventional FM. A fixed 
station may include a fixed station interface, and 
be configured as one or more base stations or 
repeaters and may include additional 
functionalities such as voters and distribution 
functions. 
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IMBE.Improved Multi-Band Excitation. A low data rate 

Voice codec developed by Digital Voice Systems, 
Inc. (DVSI) used by P25 systems. 

Mobile.A Subscriber Unit intended for vehicular operation. 

Portable.A Subscriber Unit intended for hand-held 

operation. 

Repeater.Equipment within a fixed station subsystem that 


performs at least the radio functions of power 
amplifier (PA), RF front-end, modulation and 
demodulation. It may include a limited number of 
functions such as NAC detection, CTCSS/DCS 
detection to enable repeater functions etc. It need 
not include a connection to a console or RFSS 
through a Fixed Station interface. 

RTP Header.The part of the RTP header which includes the 

following information: version (V), padding (P), 
extension (X), CSRC count (CC) {when inserted 
by a mixer}, marker (M), payload type (PT), 
sequence number, timestamp, SSRC, and CSRC. 


Tone Remote Control.A legacy method of controlling fixed station 

functions using in-band tones over analog bearers. 

Wildcard.TRC functions that can be used for generic 


purposes via the terminating fixed station. 
Equipment that support Wildcard functions can 
use these to control additional fixed station 
functions or to control equipment external to the 
fixed station - for example start and stop of power 
generators. 
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5 Abbreviations and Acronyms 

ACK.Acknowledgement 

AFSI.Analog Fixed Station Interface 

ANSI.American National Standards Institute 

CAI.P25 Common Air Interface 

CDCSS.Continuous Digital Controlled Squelch System 

CFM.Conventional FM 

CFSH.Conventional Fixed Station Host 

CFSI.Conventional Fixed Station Interface 

COR.Carrier On Relay 

CS.Connected State 

CTCSS.Continuous Tone Controlled Squelch System 

DARPA.Defense Advanced Research Projects Agency 

DFSI.Digital Fixed Station Interface 

DSCP.Differentiated Services Code Point 

DUID.Digital Unit IDentification 

DVSI.Digital Voice Systems Inc. 

E&M. Ear& Mouth Signaling 

EIA.Electronics Industry Association 

FDMA.Frequency Division Multiple Access 

FM.Frequency Modulation 

FS.Fixed Station 

FSSI.Fixed Station Subsystem Interface 

FT.Frame Type 

HLGT.High-level Guard Tone 

IANA.Internet Assigned Numbers Authority 

ICMP.Internet Control Message Protocol 

ID.IDentification 

IETF.Internet Engineering Task Force 

IMBE™.Improved Multi-band Excitation 

IP.Internet Protocol 
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LLGT.Low-level Guard Tone 

LSB.Least Significant Byte 

mA.milliamp 

MFID.ManuFacturer IDentification 

MSB.Most Significant Byte 

msec.millisecond 

N/A.Not Applicable 

NAC.Network Access Code 

NAK.Negative Acknowledgement 

OSI.Open Systems Interconnection 

P25.Project 25 

PA.Power Amplifier 

PID.Protocol IDentifier 

PTT.Push-to-talk 

RF.Radio Frequency 

RFC.Request for Comments 

RFSS.RF Subsystem 

RTCP.Real-time Transport Control Protocol 

RTP.Real-time Transport Protocol 

SBC.Single Block Control 

SF.Super Frame 

sec.second 

SSRC.Synchronization SouRCe 

TCP.Transport Control Protocol 

TIA.Telecommunications Industry Association 

TRC.Tone Remote Control 

UDP.User Datagram Protocol 

VC.Voice Conveyance 


NOTE: Abbreviations for specific fields of the RTP, UDP and IP protocols can be 
found in the relevant references. 
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6 CFSI Architecture 

This section describes the architecture of the Conventional Fixed Station Interface 
(CFSI) and is primarily informative in nature. Normative statements contained 
herein, however, are intended to be a part of this specification. 


6.1 Core CFSI Functions 

6.1.1 Conventional Analog Fixed Stations 

Conventional Analog Fixed Stations provide mobile-to-mobile and mobile-to-console 
communications compliant with TIA/EIA 603 (see [2]). Conventional stations may 
“repeat” audio from their inbound channel to their outbound channel, or may only 
forward audio received from the fixed equipment. 

Conventional Analog Fixed Stations may provide CTCSS or CDCSS squelch 
capabilities, or may be set to pass all received audio. Consoles are typically able to 
control the squelch characteristics, transmit and receive frequencies, and repeat 
mode of conventional stations. 

Conventional Analog Fixed Stations may use either the Analog or Digital Fixed 
Station Interface. 


6.1.2 Conventional Digital Fixed Stations 

Conventional Digital Fixed Stations provide similar capabilities to those provided by 
analog fixed stations, but they use the P25 CAI rather than a TIA/EIA 603 air 
interface. Instead of CTCSS and CDCSS squelch, the Conventional Digital Fixed 
Stations provide squelch mechanisms based on Network Access Code (NAC) and 
talk-group. Digital Fixed Stations may also operate clear or encrypted. 

NOTE'. The digital fixed station interface does not control secure mode and only 
exerts limited control over the squelch mode. 

Conventional Digital Fixed Stations may use either the Analog or Digital Fixed 
Station Interface. 


6.1.3 Mixed Mode Fixed Stations 

Certain fixed stations may provide both analog and digital modes. These stations 
also typically support console controls to switch between modes. 

Mixed Mode Fixed Stations may use either the Analog or Digital Fixed Station 
Interface. 
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6.2 CFSI System Architecture and Overview 

Figure 1 illustrates the architecture and context of the conventional FSI. Within the 
subsystem “cloud”, the interconnection of the elements is manufacturer specific and 
not described in this specification. 


Figure 1 - CFSI System Architecture 



Outside of the cloud, however, each fixed station is connected via either an Analog 
Fixed Station Interface (AFSI) or a Digital Fixed Station Interface (DFSI) to one host, 
which may be either a Console Subsystem (of which a console is a functional 
element) or an RFSS. Any host may support a multiplicity of fixed station interfaces 
of any variety. The analog FSI supports only the simple model of a conventional FM 
(CFM) station. In contrast, the Digital FSI supports more complex models 
appropriate to the P25 CAI. 

NOTE'. Unless otherwise indicated, for the purposes of this document “host” or 
“Host” refers to a Conventional Fixed Station Host (CFSH) as defined in this 
document. 
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Each fixed station supports one inbound and one outbound audio stream at any 
particular time. The composition of the stream is determined by the source. This 
architecture should not be construed as prohibiting multi-drop consoles, particularly 
in the analog case. Additional operator positions are transparent to the interface as 
they reside behind the abstraction presented by the CFSH. 


6.2.1 Analog Fixed Station Interface 

The analog fixed station interface models an analog station as a single fixed station 
connected via a 2 or 4 wire audio interface with 1 or 2 additional optional control 
signals to a single host. Control may be provided using the optional E&M (COR/PTT) 
signalling on the control signals, or through in-band tones. Figure 2 illustrates the 
conventional Analog Fixed Station Interface (AFSI). 

Figure 2 - Conventional Analog Fixed Station Interface 



Audio from the Host is sent to the fixed station where it is transmitted to subscriber 
units. Likewise, audio received by the fixed station from subscribers is transmitted to 
the host. Two repeat modes may be supported: 

1. The fixed station may be configured to retransmit on the outbound air 
interface the voice stream it is receiving via the inbound air interface. This 
configuration would be overridden by a transmission from the CFSH. 

2. If the connection is full-duplex, the CFSH may optionally send the audio 
received from the fixed station back to the fixed station for retransmission so 
that other subscriber units can hear. 


6.2.2 Digital Fixed Station Interface 

The Digital Fixed Station Interface employs Internet protocols to provide connectivity 
between a conventional fixed station host (CFSH) and a fixed station. The DFSI has 
two parts, a Control Service and a Voice Conveyance Service. The control service is 
modeled as a point-to-point connection between the host and a fixed station control 
service. The Voice Conveyance service is modeled as a point to multi-point 
connection between a host and one or more end-points sharing a single destination 
IP address and port, but with potentially different source IP addresses and ports. 
Thus a CFSH sends RTP based voice packets to a single address, but may receive 
them from different addresses. This arrangement is illustrated in Figure 3. 
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Figure 3 - Conventional Digital Fixed Station Interface 



6.2.2.1 Control Service 

The control service is concerned with providing control functions analogous to those 
provided by the analog fixed station interface, and with establishing and maintaining 
connectivity with the fixed station. The fixed station service is provided at a well- 
known UDP port and the host port is variable. The well-known fixed station control 
service port has a default value specified in 8.2, but may be programmable on a 
station-by-station basis. 

The control service is also responsible for: 

1. Control of the fixed station by its host including squelch disable. 

2. Transport of emergency alert and other conventional control messages from 
the fixed station to its host. 


6.2.2.2 Voice Conveyance Service 

The voice conveyance service is concerned with the passing of RTP payloads 
between the host and the fixed station. Depending on the air interface supported by 
the fixed station, the RTP payload may carry either Common Air Interface voice 
(encoded with IMBE and potentially encrypted) or waveform coded voice. Both the 
CFSH and the Fixed Station learn the UDP/RTP ports to be used for the Voice 
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Conveyance Service upon connectivity establishment by the control service. As with 
the Analog Fixed Station Interface, two repeat modes may be supported. 

1. The fixed station may be configured to retransmit on the outbound air 
interface the voice stream it is receiving via the inbound air interface. This 
configuration would be overridden by a transmission from the CFSH. 

2. The CFSH may optionally send the audio received from the fixed station back 
to the fixed station for retransmission so that other subscriber units can hear. 

The voice conveyance service is responsible for: 

1. Transport of full-duplex clear audio between the fixed station and its host. 

2. Conveyance of PTT signaling between the fixed station and its host. 

3. Providing intercom capabilities between the fixed station and its host. 

4. Transport of encrypted audio between the fixed station and its host. 

5. Transport of Caller-1 D information between the fixed station and its host. 

6. Transport of Talk-group information between the fixed station and its host. 

7. Transport of NAC code information between the fixed station and its host. 

8. Transport of Emergency Call indicators between the fixed station and its host. 

9. Transport of voter identification from the fixed station to its host. 
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7 CFSI Analog Interface 

There shall be Standard Options allowing control of the Fixed Station (FS) using 
legacy analog circuits. Both E & M and Tone Remote Control analog circuits shall be 
available as Standard Options. 


7.1 E & M 

The intent of this requirement is to be compatible with E & M interfaces used in 
legacy, pre-P25 analog fixed stations. 

The circuit shall be comprised of these signal pairs: 

• A “Transmit” pair to convey analog audio to the Fixed Station transmitter. 

• A “Receive” pair to convey analog audio from the Fixed Station receiver. 

• An “E” pair to control the RF transmission of audio on the Transmit pair via the 
Fixed Station. 

• An “M” pair to indicate the presence of signal being received by the Fixed 
Station. Use of the M-pair by the Host is optional. 

The FS shall accept an audio signal range of -30 dBm to +10 dBm on the transmit 
audio pair. Over this range the transmitter shall be capable of providing full 
perceived audio modulation in either analog or digital RF modes. When receiving full 
perceived audio modulation the FS shall be capable of generating to the receive 
audio pair an audio signal range that encompasses -30 dBm to the maximum limit 
permitted by leased circuit compliance (e.g. FCC Part 68). 

NOTE'. Some legacy analog equipment use signal levels on the audio pairs as 
high as +10 dBm to compensate for long line losses. However, +10 dBm levels 
may conflict with present compliance requirements. 

The E & M pairs are allowed to support E & M telephony standards as outlined in 
Section 9 of Telcordia GR-506 (see [3]), However, the following configuration shall 
be available to the installer ensuring support of legacy equipment. The E-pair shall 
have a configuration that expects the Host end to provide a dry contact closure while 
RF transmission of the audio on the Transmit pair is desired. The M-pair shall have a 
configuration that provides a dry contact closure while a compatible RF carrier is 
being received. The E & M pairs shall work over a range of 5 to 150 mA current with 
50 ohm maximum contact resistance while the contacts are closed, and 10 to 60 
Vdc with 5 megohm minimum resistance while the contacts are open. The E-pair 
shall limit its current to this range. 

The electrical characteristics of the signal pairs shall comply with the applicable 
requirements of Section 4 of TIA/EIA-IS-968 (see [4]). TIA/EIA-IS-968 is the basis for 
US Government 47 CFR Part 68 (FCC Part 68). 
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The Transmit and Receive pairs shall be capable of being combined on a single pair 
which may be simplex, rather than full duplex. 

Figure 4 shows the possible E & M interface configurations. In configurations which 
use a combined Transmit and Receive pair in a simplex mode, Transmit (FS E-pair 
active) shall have priority over Receive and shall silence Receive pair audio and 
shall make the FS M-pair inactive for the duration of the FS E-pair activation. 

Figure 4- Possible E&M Interface Configurations 



7.2 Tone Remote Control 

The intent of this requirement is to be compatible with Tone Remote Control (TRC) 
interfaces used in legacy, pre-P25 analog fixed stations. 

The circuit shall be comprised of these signal pairs: 

• A “Transmit” pair to convey analog audio to the Fixed Station transmitter, and to 
convey in-band control tones to the Fixed Station. 

• A “Receive” pair to convey analog audio from the Fixed Station receiver. 

The electrical characteristics of the signal pairs shall comply with the applicable 
requirements of Section 4 of TIA/EIA-IS-968 (see [4]). TIA/EIA-IS-968 is the basis for 
US Government 47 CFR Part 68 (FCC Part 68). 
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7.2.1 Simplex Wireline Interface for Configuration 6 

The Transmit and Receive pairs shall be capable of being combined on a single pair 
which may be simplex, rather than full duplex. 

Figure 5 shows the possible TRC interface configurations. In configurations which 
use a combined Transmit and Receive pair in a simplex mode, the Fixed Station 
shall be able to decode an incoming TRC sequence even while Receive audio is 
present. If the TRC sequence is a transmit sequence the Fixed Station shall mute 
any Receive audio on the audio pair for the duration of the transmission. 

NOTE'. When using a 2-wire, simplex interface it is not possible for a console to 
take-over repeat audio. 

Figure 5 - Possible TRC Interface Configurations 



In addition to audio, the Transmit pair shall contain in-band TRC tones described in 
the sections that follow. 


7.2.2 Non-Transmit Sequence 

Figure 6 shows a TRC sequence that is used to control the Fixed Station without 
causing speech transmission over the RF channel. The sequence begins with a 
burst of High Level Guard Tone (HLGT) followed by a burst of Function Tone. 
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Figure 6 - Non-Transmit TRC Sequence 


Function 

Tone 


40 ms, 

-10 db 
relative 
to 

HLGT * 

7.2.3 Transmit Sequence 

Figure 7 shows a TRC sequence that is used to control a Fixed Station RF 
transmission. The sequence begins with a burst of High Level Guard Tone (HLGT) 
followed by a burst of Function Tone, followed by Low Level Guard Tone (LLGT) 
summed with transmit speech and is present for the duration of the speech 
transmission. 



High 


Level 


Guard 


Tone 


(HLGT) 


120 ms 

◄-► 


Figure 7 - Transmit TRC Sequence 


High 


Level 

Guard 

Tone 

Function 

Tone 

Transmitted Speech 

Low Level Guard Tone (LLGT) 

(HLGT) 



i For the duration of the transmission, i 

Average Speech -6 to -18 db relative to HLGT, 
summed with LLTG -30 db relative to HLGT 

120 ms—► 

40 ms/ 
-10 db 
relative 


to 

HLGT 

r*-RF transmission of speech-►! 


7.2.4 Guard Tones 

The duration of the High Level Guard Tone (HLGT) shall be nominally 
120 milliseconds. The Low Level Guard Tone (LLGT) shall be nominally 30 db below 
HLGT and shall be summed with the speech intended for transmission. The LLGT 
should be filtered out prior to audio modulation of the RF transmission. The duration 
of the LLGT shall be for the duration of the speech transmission. The tone frequency 
used for the HLGT and LLGT shall be the same, and shall be one of the following 
field selectable values: 2100 Hz, 2175 Hz or 2325 Hz, with 2175 Hz being the 
default. The Guard Tone detector of the Fixed Station shall recognize the tone as 
valid within 10 Hz of the selected Guard Tone, and shall consider invalid tones 20 
Hz or more from the selected Guard Tone. The Transmit pair of the FS shall be 
capable of accepting a HLGT range of-30 dBm to +10 dBm. 
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NOTE : The Host equipment generating the Guard Tone should maintain a 
tolerance of +/- 5 Hz. Some legacy analog host equipment use signal levels on 
the audio pairs as high as +10 dBm to compensate for long line losses. However, 
+ 10 dBm levels may conflict with present compliance requirements (e.g. FCC 
Part 68). 

7.2.5 Function Tone 

The duration of the Function Tone shall be nominally 40 milliseconds and shall be 
nominally 10 db below HLGT. The possible Function Tones shall be among the 15 
tones listed Table 1. Table 2 outlines the functions that shall be supported by the FS 
and the recommended Functions Tone to be used for each of those functions. Table 
1 shows six recommended mappings of Function Tones, one or more of which are 
generally compatible with legacy Host equipment. Manufacturers may optionally 
support additional Function Tones and may support additional features controlled by 
any of the Function Tones. However, when the Fixed Station is configured to support 
features listed in Table 1, it shall be possible to use the Function Tones designated 
in the Tables 1 and 2 to control those features. 
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Table 1 - TRC Function Tones vs. Possible FS Functions 


Tone 

(Hz) 

Simple Keying 
Command 




Wild 

Card 

Other 

None 



Intercom 




2050 



Monitor 

without 

receive 

code be 

Monitor 

without 

receive 

code b,e 



1950 

Xmit on selected 
channel 3 , mode c,d 
and/or code b,d 

Xmit on 
chan 1 d 

Select 
chan 1 




1850 

Xmit on channel 3 1 
without code b,d 

Xmit on 
chan 2 d 

Select 
chan 2 




1750 


Xmit on 
chan 7 d 

Select 
chan 7 

Select 
code E 

Second 

receiver 

Off 

Receiver 

maximum 

squelch 

1650 


Xmit on 
chan 8 d 

Select 
chan 8 

Select 
code F 

Second 

receiver 

On 

Receiver 

minimum 

squelch 

1550 




Select 
code G 

Repeat 

Off 


1450 




Select 
code H 

Repeat 

On 


1350 


Xmit on 
chan 3 d 

Select 
chan 3 

Select 
code A 

Wildcard 

1 On 

Select 
Digital RF 
Mode 0 

1250 


Xmit on 
chan 4 d 

Select 
chan 4 

Select 
code B 

Wildcard 

1 Off 

Select 

Analog 

RF Mode 0 

1150 


Xmit on 
chan 5 d 

Select 
chan 5 

Select 
code C 

Wildcard 

2 On 

Select 

Coded 

Speech 

1050 


Xmit on 
chan 6 d 

Select 
chan 6 

Select 
code D 

Wildcard 

2 Off 

Select 

Clear 

Speech 

950 






Special 

850 






Special 

750 






Special 

650 






Special 


Table Notes: 

a - “Channels” may be either conventional frequencies, or talk groups. 
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b - “Codes” may be either analog CTCSS/DCS (subaudible squelch), or digital 
NAC. 

c - Although the interface may be analog, the RF mode may be either analog or 
digital. 

d - Individual channel parameters may include default code, secure mode 
(coded/clear) and RF mode (analog/digital) settings. Unless the channel 
parameters include default codes and modes, the transmission shall use the 
previously selected code, secure mode and RF mode. 

e - Monitor (listen to all channel traffic without regard to code) is canceled by any 
Transmit or Channel Selection TRC sequence. 

Table 2 - Possible FS Functions vs. TRC Function Tones 


Function 

TRC Sequence Type 

Function Tone (Hz) 

Intercom 

None 

None 

Monitor without receive 
code b,e 

Non-Transmit 

2050 

Transmit on selected 
channel 3 , mode c,d and/or 
code b,d 

Transmit 

1950 

Transmit on channel 1 d 

Transmit 

1950 

Transmit on channel 3 1 
without code b,d 

Transmit 

1850 

Transmit on channel 2 d 

Transmit 

1850 

Transmit on channel 3 d 

Transmit 

1350 

Transmit on channel 4 d 

Transmit 

1250 

Transmit on channel 5 d 

Transmit 

1150 

Transmit on channel 6 d 

Transmit 

1050 

Transmit on channel 7 d 

Transmit 

1750 

Transmit on channel 8 d 

Transmit 

1650 

Select channel 1 

Non-Transmit 

1950 

Select channel 2 

Non-Transmit 

1850 

Select channel 3 

Non-Transmit 

1350 

Select channel 4 

Non-Transmit 

1250 

Select channel 5 

Non-Transmit 

1150 

Select channel 6 

Non-Transmit 

1050 

Select channel 7 

Non-Transmit 

1750 

Select channel 8 

Non-Transmit 

1650 

Select code A 

Non-Transmit 

1350 

Select code B 

Non-Transmit 

1250 

Select code C 

Non-Transmit 

1150 

Select code D 

Non-Transmit 

1050 

Select code E 

Non-Transmit 

1750 

Select code F 

Non-Transmit 

1650 
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Table 2 - Possible FS Functions vs. TRC Function Tones (concluded) 


Function 

TRC Sequence Type 

Function Tone (Hz) 

Select code G 

Non-Transmit 

1550 

Select code H 

Non-Transmit 

1450 

Select Digital RF Mode 0 

Non-Transmit 

1350 

Select Analog RF Mode 0 

Non-Transmit 

1250 

Select Coded Speech 

Non-Transmit 

1150 

Select Clear Speech 

Non-Transmit 

1050 

Repeat On 

Non-Transmit 

1450 

Repeat Off 

Non-Transmit 

1550 

Second receiver On 

Non-Transmit 

1650 

Second receiver Off 

Non-Transmit 

1750 

Receiver maximum 
squelch 

Non-Transmit 

1750 

Receiver minimum 
squelch 

Non-Transmit 

1650 

Wildcard 1 On 

Non-Transmit 

1350 

Wildcard 1 Off 

Non-Transmit 

1250 

Wildcard 2 On 

Non-Transmit 

1150 

Wildcard 2 Off 

Non-Transmit 

1050 

Special 

Transmit or Non-Transmit 

950 

Special 

Transmit or Non-Transmit 

850 

Special 

Transmit or Non-Transmit 

750 

Special 

Transmit or Non-Transmit 

650 


7.2.6 Speech 

Speech intended for RF transmission by the Fixed Station shall be summed with 
LLGT, and shall have an average level that is -6 to -18 db below HLGT. 

NOTE: The Host equipment generating the tones should also filter the Guard 
Tone frequency from the speech prior to summing with the speech with the LLGT 
otherwise phase coincidence may cause apparent gaps in the presence of the 
LLGT resulting in unintentionally dropping the RF transmission. It may be 
desirable to be able to adjust the speech level relative to the tone levels within 
the Fixed Station to ensure greatest compatibility with legacy Host equipment. 


7.2.7 Sequence Off Time 

Following either type of TRC sequence there shall be a minimum of 300 ms before 
another TRC sequence is sent. 
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7.3 Intercom 

It shall be possible, as a Standard Option, to send speech between the Host and the 
Fixed Station without any accompanying TRC sequence or E & M-pair keying. This 
may be used for intercom purposes only, rather than to transmit RF. 
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8 CFSI Digital Interface 

Note that except for the definition of the control messages (see 8.3), throughout this 
description, the conventions of Appendix B of RFC791 (see [1]) are used, that is, for 
multi-byte fields, information is transmitted most significant byte first and bit 0 
represents the most significant bit of each byte. In 8.3, bytes are transmitted in the 
order described, and bit 0 represents the least significant bit of each byte. 


8.1 Internet Protocol Overview 

The Internet architecture layers (see Figure 8 for a mapping to the OSI model) are 
used to construct the Digital Fixed Station Interface (DFSI) protocol stack (illustrated 
in Figure 9). The non-proprietary protocols that make up the Internet protocol suite 
have become widely implemented standards because of the success of the Internet, 
and are supported by the widest variety of network equipment vendors. This allows 
the networks to connect DFSI equipment to be built with common off the shelf 
equipment, either by a user organization or a specialist network provider. Because 
the Internet architecture layers were developed much earlier than the Open Systems 
Interconnection (OSI) model they can only be roughly mapped to it (see Figure 8). 

Figure 8 - Internet Architecture Layers and the OSI Layers 


Internet Architecture Layers OSI Layers 




Application 

Application 


Presentation 



Session 

Transport (i.e., Host-to-Host) 


T ransport 

Network (i.e., Internet) 


Network 

Lower Layers 
(i.e., Data Link and 
Physical) 


Data Link 


Physical 
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Figure 9 - DFSI Internet Protocol Suite 
Internet Architecture Layers DFSI Protocol Suite 


The following sections describe each of the layers of the Digital FSI (DFSI) Internet 
Protocol Suite, through the Transport Layer. 

8.1.1 DFSI Lower Layers 

These layers correspond to the physical and data link layers of the OSI layers. The 
Internet protocols, designed to be hardware independent, do not cover these lowest 
two OSI layers. As a result, the protocols of the Internet suite are widely used to 
connect heterogeneous systems. 

The following specific lower layer requirements apply to the Digital Fixed Station 
Interface: 

• Equipment conforming to DFSI shall offer the option of Ethernet 100 Base-T 
with a RJ-45 connector as the physical and data link layers. 

• Equipment may offer any industry standard physical and link layer protocols 
that support the internet protocol, in addition to Ethernet 100 Base-T. 

The network carrying the DFSI may change data link and physical protocols. 
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8.1.2 Network Layer 

This layer corresponds to the OSI network layer, supporting routing of the packets 
through the network from the source host to the destination host or hosts. At this 
layer of the Internet, the main protocol is the Internet Protocol (IP). In addition, there 
are several control protocols. 

IP is a connectionless packet protocol. Packets are groups of information transmitted 
as a unit to and from the upper layer protocols on sending and receiving hosts, and 
delivered from the sending to the receiving host over interconnected systems. Each 
IP packet includes an IP header that includes source and destination IP addresses. 

There are two styles of IP address, unicast addresses allow packets to be routed to 
a single, particular host. Multicast addresses allow packets to be routed to an 
arbitrary collection of hosts. IP multicast offers a convenient mechanism to distribute 
data or voice to multiple hosts which suppliers of fixed station subsystems may use 
to implement the distribution function shown in Figure 1. Equipment conforming to 
the DFSI shall support unicast IP addresses. CFSH equipment conforming to the 
DFSI shall be able to send to IP multicast addresses. 

There are two versions of the Internet protocol currently in use, IPv4 (see [1]) and 
IPv6 (see [5]). The equipment conforming to the DFSI shall support IPv4. This 
interface has been designed to work with IPv4. Use of this interface with IPv6 is for 
further study. 


8.1.3 Transport Layer 

This layer corresponds roughly to the OSI transport layer. Protocols at this layer 
communicate with peer processes in other hosts or networked devices. Two key 
host-to-host protocols at this layer are the User Datagram Protocol (UDP) (see [6]) 
and Transmission Control Protocol (TCP) (see [15]). 

TCP is not well-suited to real-time applications, and it can not be used with IP 
multicast, whereas UDP is a simple connectionless datagram protocol. Therefore, 
TCP is not used in the DFSI. 


8.1.3.1 RTP 

The main feature that UDP provides is multiplexing of application protocols using the 
mechanism of port numbers which, along with an integrity checksum, are the only 
contents of the UDP header. 

UDP does not provide "reliable" transport, there are no mechanisms to recover from 
lost packets or prevent packets form being delivered out of order. To regain some of 
the transport layer facilities that are not provided in UDP without incurring the 
penalties of TCP, the Real-time Transport Protocol (RTP) (see [7]) is often used. 

RTP provides detection of lost packets and out-of-order packets. 
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8.1.3.2 Requirement 

Equipment conforming to the DFSI shall transport the control service over UDP only. 
Equipment conforming to the DFSI shall transport the voice conveyance Service 
over RTP on UDP. 

8.1.3.3 RTCP Considerations 

The Real-time Transport Control Protocol (RTCP) is a companion to RTP. 

Equipment may send RTCP reports as described in RFC 3550 (see [7]), but shall 
not depend on other equipment sending such reports. 


8.1.4 Transport and Network Layer Parameters 

The following sub-clauses specify the values of transport and network layer 
parameters for the DFSI. 

8.1.4.1 IP Address 

In accordance with 8.2, the IP addresses of the fixed station are configured in the 
host and the IP address of the host is learned by the fixed station. Specific 
addresses for both unicast and multicast operation are at the discretion of 
infrastructure designers. 

8.1.4.2 DSCP Value 

So that Differentiated Service enabled network equipment as described in RFC 2475 
(see [16]) can give this traffic appropriate handling, equipment using this interface 
should set the Differentiated Services Code Point (DSCP) field of the IP headers as 
in Table 3. 


Table 3-DSCP Values 


Voice Traffic 

101110 

Expedited forwarding (EF). 

Control 

T raffic 

100010 

Assured forwarding class 4 Low drop 


More details of expedited forwarding can be found in RFC 2598 (see [13]). 

8.1.4.3 UDP Port Number 

In accordance with 8.2, the UDP ports of the fixed station are configured in the host, 
and the fixed station learns the ports of the host. Specified port assignments are at 
the discretion of system designers. 

8.1.4.4 RTP Padding Flag P 

Implementers should set this to the appropriate value according to RFC 3550 (see 

[7]). 
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8.1.4.5 RTP Header Extension Flag X 

Payload independent header extension is not used by the DFSI so X = 0. 

8.1.4.6 RTP Payload Type 

This interface shall use the dynamic payload type; type 100 (decimal). 

8.1.4.7 RTP Marker Bit 

The marker bit of the RTP header shall be set to 0. 

8.1.4.8 RTP Time Stamp 

In accordance with typical sampling rates used by voice codecs, 8 kHz shall be used 
as the clock rate for the timestamp. 

8.1.4.9 CSRC 

Radio networks rather than combining all signals in a conference bridge typically use 
techniques such as voting so that only one input voice stream contributes to the 
transmitted voice stream. There is therefore no need for a list of contributing 
synchronization sources. Therefore there shall be no Contributing Source (CSRC) 
list in DFSI RTP packets. 

8.1.4.10 SSRC 

Synchronization Sources (SSRCs) are selected by the host and assigned to the 
fixed stations through the connection protocol as described in 8.3. 
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8.2 DFSI Configuration Items 

The following must be preconfigured as indicated in Table 4. 

Table 4 - Configuration Items for the DFSI 


Configuration Item 

Entity^ 

Purpose 

Default 

Value 

Fixed Station Control 

IP Address 

B 

IP Address at which the fixed 
station subsystem supplies the 
Control Service. This shall be a 
unicast IP address. 

N/A 

Fixed Station Voice 

IP Address 

B 

IP Address at which the fixed 
station subsystem receives, 
outbound voice conveyance 
service traffic. This may a unicast 
or multicast IP address. It may be 
the same as or differ from the 

Fixed Station Control IP Address. 

None 

Fixed Station Control 
Port 

B 

UDP Port at which the fixed station 
supplies the Control Service. 

7000 

Fixed Station Voice 
Conveyance Port 

S 

UDP Port at which RTP traffic is 
conveyed to the fixed station. 
Provisioned in Connection 
Establishment Response. 

None 

Fixed Station RTCP 
Voice Conveyance 
port 

S 

UDP port at which RTCP traffic 
may be conveyed. Note that RTCP 
traffic is not required in the DFSI. 

None 

Host IP Address 

H 

The IP Address of the Host. This 
shall be a unicast IP address. 

None 

Control Retry Timer 

B 

Retry period for control messages. 

500 msec 

Control Attempt Limit 

B 

Maximum number of attempts for 
control messages. 

3 

Connectivity Tx Timer 

B 

Periodicity of control heartbeats 

5 sec 

Connectivity Loss 

Limit 

B 

Maximum number of heartbeat 
losses to allow. 

2 

FS Heartbeat Period 

H 

Periodicity of Fixed Station 
Heartbeats. This value is 
provisioned to the fixed station in 
the “Establish Connection” 
message. 

30 sec 


3 H = Host, S = Fixed Station, B = Both 


29 




TIA-102.BAHA 


Table 4 - Configuration Items (concluded) 


Configuration Item 

Entity 

Purpose 

Default 

Value 

Host Heartbeat 

Period 

H 

Periodicity of Host Heartbeats. 

This value is provisioned to the 
fixed station in the “Establish 
Connection” message. 

30 sec 

Voter Reporting 

Period 

S 

Periodicity of voter reports. 

10 sec 


8.3 DFSI Control Service 
8.3.1 Control Messages 

Table 5 summarizes the Control Service message set. 

Table 5 - Control Service Message Set Mnemonics 


Mnemonic 

Message ID 

Meaning/Purpose 

FSC_CONNECT 

0 

Establish a connection with a Fixed 
Station 

FSC_HEARTBEAT 

1 

Heartbeat/Connectivity Maintenance 

FSC_ACK 

2 

Control Service Acknowledgement 

FSC_SBC 

3 

Single Block Control 

FSC_MAN_EXT 

4 

Manufacturer Extension 

FSC_SEL_CHAN 

5 

Channel Selection Command 

FSC_SEL_RPT 

6 

Repeat Mode Selection 

FSC_SEL_SQUELCH 

7 

Squelch Mode Selection 

FSC_REPORT_SEL 

8 

Report Selected Modes 

FSC_DISCONNECT 

9 

Detach Control Service 


All messages have a Message ID and Message version field. And all messages 
except Heartbeat and Acknowledgement have a Message Correlation Tag. The 
Message ID and Message version fields are fixed values determined by this 
specification. The Correlation Tag shall be selected by the source of the message 
and echoed back in its acknowledgement. Retries of any message shall be 
indistinguishable from the original message. 
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8.3.1.1 Establish Connection 

The Establish Connection command may be sent by the host to establish a 
connection with the fixed station. It can only be sent by the host. Figure 10 
illustrates data for the establish connection command. 

Figure 10 - Data for the Establish Connection Command 


FSC_CONNECT 

1 


Bits 8-15 
Bits 0-7 
Bits 24-31 
Bits 16-23 
Bits 8-15 
Bits 0-7 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 

3 

4 

5 

6 

7 

8 
9 

10 


Message ID 


Message Version 


Message Correlation Tag 


VC Base Port (MSB) 


VC Base Port (LSB) 


VC SSRC (MSB) 


VC SSRC (Next MS bits) 


VC SSRC (Next MS bits) 


VC SSRC (LSB) 


FS Heartbeat Period 


Host Heartbeat Period 


VC Base Port = The host Voice Conveyance RTP Port. By rule, the RTCP port 
(unused but reserved) is ((VC Base Port) + 1). 

VC SSRC - The SSRC identifier to be used by the fixed station on all RTP 
transmissions sent to the host. VC SSRC shall be selected by the host to be unique 
in the context of the host at any particular time. 

FS Heartbeat Period - The period at which the fixed station should send 
FSC_HEARTBEAT messages to the host control port. The FS Heartbeat Period is in 
units of seconds and is restricted to the range 5 to 255. 

Host Heartbeat Period - The period at which the host will send FSC_HEARTBEAT 
messages to the fixed station control port. The Host Heartbeat Period is in units of 
seconds and is restricted to the range 5 to 255. 

The response data for this command shall be as shown in Figure 11. 
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Figure 11 - Response Data for the Connection Command 


Octet 0 _ Response Version _ 

1 _ FS VC Base Port (MSB) _ 

2 FS VC Base Port (MSB) 

Bit 7 6 5 4 3 2 1 0 

FS VC Base Port = The fixed station Voice Conveyance RTP Port. By rule, the 
RTCP port (unused but reserved) is ((FS VC Base Port) + 1). 


1 

Bits 8-15 
Bits 8-15 


8.3.1.2 Control Service Heartbeat 

Figure 12 illustrates the Control Service Heartbeat message. This message is sent 
periodically by both the fixed station and the CFSH to establish and maintain 
connectivity of the control server and client. 

Figure 12 - Message for Control Service Heartbeat 


Octet 0 
1 


Heartbeat Message ID 
Message Version 


FSC_HEARTBEAT 

1 


8.3.1.3 Control Service Acknowledgement 

The Control Service Acknowledgement is used by both the client and the server to 
positively or negatively acknowledge the receipt of a control service message. It 
contains the identifying information of the message being acknowledged along with 
an ACK/NAK code and optional response data. Figure 13 illustrates the control 
service acknowledgement message. 
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Figure 13 - Message for Control Service Acknowledgement 


FSC_ACK 

1 

From msg being 
ack’d. 

From msg being 
ack’d. 

From msg being 
ack’d. 


Bit 7 6 5 4 3 2 1 0 

Table 6 summarizes the ACK/NAK code values. 

Table 6 - ACK/NAK Code Values 


Octet 0 
1 
2 

3 

4 

5 

6 
7+ 


Message ID 


Message Version 


Acknowledged Message ID 


Acknowledged Message Version 


Acknowledged Message Correlation Tag 


Response code 


Response Data Length 


Response Data 


ACK/NAK 

Code 

Mnemonic 

Meaning 

0 

CONTROL ACK 

General Acknowledgement 

1 

CONTROLJMAK 

Unspecified Negative 
Acknowledgement 

2 

CONTROL_NAK_CONNECTED 

The server is connected to some 
other host 

3 

CONTROL_NAK_M_UNSUPP 

Unsupported Manufacturer 
specific message. 

4 

CONTROL NAK V UNSUPP 

Unsupported Message Version 

5 

CONTROL NAK F UNSUPP 

Unsupported Function 

6 

CONTROL_NAK_PARMS 

Bad or Unsupported Command 
Parameters 

7 

CONTROL_NAK_BUSY 

The fixed station subsystem is 
currently busy with a function that 
is incompatible with the requested 
action. 


The content of the Response Data is specified with the message definition given in 
8.3.1.4-10. 


8.3.1.4 Single Block Control Message 

The single block control message is used to convey conventional control messages 
as specified in TSB102.AABG (see [14]) and TIA/EIA-102.AABC (see [9]) between a 
fixed station and its host. Emergency Alert is one possible single block control 
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message. Either the fixed station or its host may send it. Figure 14 illustrates the 
message for single block control. 

Figure 14 - Message for Single Block Control 


FSC_SBC 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 
3 

4..12 


Message ID 


Message Version 


Message Correlation Tag 


Reserved 


Opcode 


Content 


Opcode = Control Message Opcode from TIA/EIA-102.AABC (see [9]). 

Content = Bytes 1-9 of the corresponding single block control message from 
TIA/EIA-102.AABC (see [9]). 


The Acknowledgement for this command shall have no response data (Response 
Data Length = 0). 


8.3.1.5 Manufacturer Extension Message 

The Manufacturer Extension Message may be used by manufacturers to provide 
value added and experimental extensions to the protocol. Either the fixed station or 
its host may send it. Figure 15 illustrates the message for manufacturer extension. 

Figure 15- Message for Manufacturer Extension 


FSC_MAN_EXT 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 
3 
4+ 


Message ID 


Message Version 


Message Correlation Tag 


MFID 


Manufacturer Specific Data 


The response data for a supported manufacturer extension will be specified by the 
manufacturer making the extension. 

The Acknowledgements for unsupported manufacturer extensions shall have no 
response data (Response Data Length = 0). 
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8.3.1.6 Channel Selection Command 

The Channel Selection command may be used by the host to select a particular RF 
channel for receive operations. Only the host may send the Channel Selection 
Command. Figure 16 illustrates the command for channel selection. 

Figure 16 - Command for Channel Selection 


FSC_SEL_CHAN 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 

3 

4 


Message ID 


Message Version 


Message Correlation Tag 


Receive Channel Number 


Transmit Channel Number 


Receive Channel Number = Channel number for receive operations. The specific 
meaning of the Channel Number parameter may be manufacturer specific. 

Transmit Channel Number - Channel Number for transmit operations. The specific 
meaning of the Channel Number parameter may be manufacturer specific. 

The Acknowledgement for this command shall have no response data (Response 
Data Length = 0). 


8.3.1.7 Repeat Mode Selection Command 

The Repeat Mode selection shall allow a host to select between the repeat and non¬ 
repeat modes of a fixed station. Only the host may send the Repeat Mode Selection 
command. Figure 17 illustrates the command for repeat mode selection. 

Figure 17 - Command for Repeat Mode Selection 


FSC_SEL_RPT 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 
3 


Message ID 


Message Version 


Message Correlation Tag 


Repeat Mode 


Repeat Mode = 0, Do Not repeat inbound audio on outbound channel; 

= 1, Repeat inbound audio; 

= otherwise, illegal. 


The Acknowledgement for this command shall have no response data (Response 
Data Length = 0). 
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8.3.1.8 Squelch Control Message 

The Squelch control message is used by the host to select the Squelch mode of the 
fixed station. Monitor mode defeats all Squelch processing. The existing Squelch is 
restored by selecting monitor mode off. Figure 18 illustrates the message for 
Squelch control. 


Figure 18 - Message for Squelch Control 


FSC_SEL_SQUELCH 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 
3 


Message ID 


Message Version 


Message Correlation Tag 


Squelch Mode 


Squelch Mode 

Squelch 

Mode 

Value 

Monitor off 

0 

Monitor on 

1 


The Acknowledgement for this command shall have no response data (Response 
Data Length = 0). 

Note that Squelch type and Squelch parameters are set by configuration of the fixed 
station. 


8.3.1.9 Report Selections 

The Report Selections command may be sent by the host to cause the fixed station 
to report settings defined in the DFSI. It may only be sent by the host. Figure 19 
illustrates the command for report selections. 

Figure 19 - Command for Report Selections 


FSC_REPORT_SEL 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 


Message ID 


Message Version 


Message Correlation Tag 


The positive acknowledgements of the Report Selections command shall contain the 
response data shown in Figure 20. 
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Figure 20 - Response Data for Report Selections 


1 

2 

3 

4 
Bit 


Repeat Mode Selection = 0, Do not repeat inbound audio; 

= 1, Repeat inbound audio. 

Receive Channel Selection = Numeric representation of the selected channel. 
Transmit Channel Selection = Numeric representation of the selected channel. 
Squelch Mode - See 8.3.1.8. 


_ Report Version _ 

_ Repeat Mode Selection _ 

_ Receive Channel Selection _ 

_ Transmit Channel Selection _ 

_ Squelch Mode _ 

7 6 5 4 3 2 1 0 


8.3.1.10 Detach 

The detach command shall allow a host to tear down the connection with the fixed 
station in an orderly way. Only the host may send the Detach command. Figure 21 
illustrates the command for detach connection. 

Figure 21 - Command for Detach Connection 


FSC_DETACH 

1 


Bit 7 6 5 4 3 2 1 0 


Octet 0 
1 
2 


Message ID 


Message Version 


Message Correlation Tag 


The Acknowledgement for this command shall have no response data (Response 
Data Length = 0). 


8.3.2 Control Service Procedures 

8.3.2.1 Control Service Operational Description 

Note that all state models represented in this section are for the purpose of 
describing the DFSI protocol and should not be construed as requiring or suggesting 
any particular implementation. 
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The state model for the fixed station control service is shown in Figure 22. In the CS 
Not Connected state, the fixed station operates in whatever configuration was last 
provided by a host. Emergency alerts received by the FS while in the CS Not 
Connected state must be dealt with in accordance with local policy and manufacturer 
implementations. The FS transitions to the CS Connected state upon receipt of an 
FSC_CONNECT message. In the CS Connected state, the fixed station is able to 
respond to control messages and forward Emergency Alerts to the host. Failure to 
receive an acknowledgement (Retry Failure), the lack of a heartbeat for a sufficient 
period of time (Connectivity Timeout), the receipt of a FSC_DISCONNECT 
message, or other implementation specific connectivity loss triggers (such as the 
receipt of a ICMP Port Not Found notification) cause a transition back to the CS Not 
Connected state. 

Figure 22 - FS Control Service State Model 


Receipt of Connect 



other Connectivity Loss Trigger 


The host side of the control service protocol is similar to the fixed station side, and is 
illustrated in Figure 23. Upon receipt of an implementation specific connection 
trigger, the CFSH sends FSC_CONNECT and enters the CS Connecting state. 

Upon receipt of an acknowledgement to FSC_CONNECT, the host proceeds to the 
connected state wherein FSC_HEARTBEATS and other messages may be sent. As 
with the fixed station, failure of the retransmission protocol or connectivity protocol 
can cause a transition to the CS Not Connected state. Furthermore, the host can 
initiate a control disconnection by sending FSC_DISCONNECT and transitioning to 
the CS Disconnecting state. In this case, receipt of the acknowledgement to the 
FSC_DISCONNECT (or a connectivity or retry failure) causes the transition to CS 
Not Connected. 


38 




TIA-102.BAHA 


Figure 23 - Host Control Client State Model 



Connectivity Lost Trigger 
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8.3.2.2 Control Procedures 

The following control procedures are subject to the following general requirements: 

1. While in the CS Not Connected state, the fixed station shall silently discard all 
messages except for FSC_CONNECT and FSC_DISCONNECT. 

2. While in the CS Not Connected state, the host shall silently discard all 
messages. As described previously, air interface messages received while in 
the CS Not Connected state must be processed in accordance with local 
policy and specific manufacturer implementations. 

3. While in the CS Connecting state, the host shall silently discard all messages 
except for FSC_ACK. 

4. While in the CS Not Connected state, neither the fixed station nor the host 
shall send any messages to the other, with the exception of FSC_ACK in 
response to a FSC_DISCONNECT that might occur due to a dropped 
FSC_ACK. 

5. While in the CS Connecting state, the host shall only send FSC_CONNECT 
messages. 

6. FSC_ACK shall always be sent to the IP address and UDP port contained in 
the message being acknowledged. 

7. The host shall send all messages except for FSC_ACK to the pre-configured 
UDP control port of the fixed station. 

8. The fixed station shall send heartbeat messages to the IP address and UDP 
port derived from the FSC_CONNECT message that initiated the connection. 

9. Subject to these restrictions and those in the following procedures, the host 
may send any control message defined in 8.3.1. 

10. Subject to these restrictions and the following procedures, the fixed station 
may only send FSC_HEARTBEAT, FSC_ACK, FSC_MAN_EXT, and 
FSC_SBC messages to the host. 
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8.3.2.3 Retry Protocol 

With the exception of the Heartbeat and Acknowledgement messages, all control 
service messages shall be sent using the following retransmission protocol. Within 
the following description, “sender” refers to the host or fixed station sending the 
message, and “receiver” refers to the host or fixed station receiving the message. 

1. Upon receiving a trigger for the transmission of a message, the sender shall: 

a. Choose a correlation tag, format the message, and send it to the 
control service port of the receiver. 

b. Start a retransmission timer with the value ControlRetryTimer. 

c. Reset a retransmission counter to zero. 

2. Upon expiration of the retransmission timer, the sender shall: 

a. Increment the retransmission counter. 

b. If the value of the retransmission counter is equal to 
ControlAttemptLimit, the retry protocol has failed. The sender shall 

i. If the connectivity procedures of 8.3.2.4.3 and 8.3.2.4.4 are 
active, it shall discontinue connectivity procedures as described 
therein and revert to the CS Not Connected state. 

ii. The sender shall implement recovery procedures in accordance 
with local policy. 

c. If the value of the retransmission counter is less than 
ControlAttemptLimit, the sender shall reset the retransmission counter 
to the value Control RetryTimer and resend the message. 

3. Upon receipt of an acknowledgement, the sender shall: 

a. If the Acknowledged Message Id, Acknowledged Message Version, 
and Acknowledged Message Correlation Tag match those of an 
outstanding message, the sender shall: 

i. Cancel the retransmission timer of the outstanding message. 

ii. Perform further processing on the reply in accordance with local 
policy. 

b. Otherwise, the sender shall silently discard the acknowledgement. 

4. Upon receiving a message other than a heartbeat or acknowledgement, the 
receiver shall: 

a. If the receiver is a fixed station that is currently connected to a host, 
and the IP address or UDP port of the sender do not match those of 
the host, the receiver shall reply with FSC_ACK with the ACK/NAK 
code set to CONTROL_NAK_CONNECTED and no response data. 

b. Otherwise, if the received message is FSC_MAN_EXT and the 
receiver does not support the message, the receiver shall reply with 
FSC_ACK with the ACK/NAK code set to 
CONTROL_NAK_M_UNSUPPORTED and no response data. 
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c. Otherwise, if the received message is a known command with an 
unsupported message version, the receiver shall reply with FSC_ACK 
with the ACK/NAK code set to CONTROL_NAK_V_UNSUPP. 

d. Otherwise, the receiver shall perform message specific processing as 
specified in 8.3.2.5. 
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8.3.2.4 Connectivity Procedures 

8.3.2.4.1 Connection Establishment Procedures 

1. Upon detecting a connectivity trigger while in the CS Not Connected state, the 
host shall: 

a. Transition to the CS Connecting state. 

b. Send the FSC_CONNECT message to the Fixed Station, applying the 
retransmission protocol of 8.3.2.3. 

2. Upon receipt of the acknowledgement of FSC_CONNECT, the host shall 
enter the CS Connected state, and initiate connectivity maintenance 
procedures as described in 8.3.2.4.3. 

3. Upon failure of the retransmission protocol, or upon receipt of some other 
implementation specific connectivity lost indication, the host shall transition to 
the CS Not Connected state. 

4. Upon receipt of FSC_CONNECT in the CS Not Connected state, the fixed 
station shall: 

a. Reply with FSC_ACK with the CONTROL_ACK response code. 

b. Transition to the CS Connected state, initiate connectivity maintenance 
procedures as described in 8.3.2.4.4, and allow Voice Conveyance 
services to operate using the SSRC contained within the 
FSC_CONNECT message as the SRC identifier for the RTP protocol. 

5. Upon receipt of FSC_CONNECT in the CS Connected state, the fixed station 
shall reply with FSC_ACK message with the CONTROL_ACK response code 
if and only if the FSC_CONNECT message originated at the same IP address 
and UDP port as the FSC_CONNECT that caused the transition into the CS 
Connected state. Otherwise, the fixed station shall respond with the 
FSC_ACK with the CONTROL_NAK_CONNECTED response code. 
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8.3.2.4.2 Connection Detachment Procedures 

1. Upon detecting a connectivity trigger in the CS Not Connected state, the host 
shall: 

a. Transition to the CS Connecting state. 

b. Send the FSC_CONNECT message to the Fixed Station, applying the 
retransmission protocol of 8.3.2.3. 

2. Upon receiving the FSC_DISCONNECT message in the CS Not Connected 
state, the fixed station shall respond with FSC_ACK with a response code of 
CONTROL_ACK. 

3. Upon receiving a FSC_DISCONNECT message in the CS Connected state, 
the fixed station shall: 

a. Reply with FSC_ACK with a status code of 
CONTROL_NAK_CONNECTED if the IP address and port of the 
sender of the FSC_DISCONNECT do not match those of the sender of 
the FSC_CONNECT that caused the transition into CS Connected. 

b. Otherwise, 

i. Reply with FSC_ACK with a status code of CONTROL_ACK 
and, 

ii. The fixed station shall terminate connectivity procedures as 
described in 8.3.2.4.4. 
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8.3.2.4.3 Host Connectivity Maintenance Procedures 

1. To establish connectivity maintenance procedures, the host shall: 

a. Start a connectivity timer with the value ConnectivityTxTimer. 

b. Reset a connectivity counter to zero. 

2. To discontinue (terminate) connectivity maintenance procedures, the host 
shall: 

a. Cancel the connectivity timer. 

b. Reset the connectivity counter to zero. 

c. Discontinue all pending retransmission procedures. 

d. Discontinue the transmission and any and all packets on the Voice 
Conveyance service. 

3. A host that receives a heartbeat message in the CS Connected state shall 
perform the following if and only if the heartbeat originates from the expected 
IP address and UDP port: 

a. Reset the connectivity counter to zero. 

b. Otherwise, it shall silently discard the message. 

4. Upon receiving a heartbeat message in the any other state, the host shall 
silently discard the message. 

5. Upon expiration of the ConnectivityTxTimer, the host shall: 

a. Increment the connectivity counter. 

b. If the connectivity counter is greater than ConnectivityLossLimit, 
connectivity has been lost. The host shall enter the CS Not Connected 
state and take recovery actions in accordance with local policy. 

c. Otherwise, the host shall: 

i. Send a heartbeat to the fixed station. 

ii. Restart the connectivity timer with the value 
ConnectivityTxTimer. 
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8.3.2.4.4 Fixed Station Connectivity Maintenance Procedures 

1. To initiate connectivity maintenance procedures, the fixed station shall: 

a. Reset a connectivity counter to zero. 

b. Start a connectivity timer with the value FSConnectivityTxTimer. 

2. To discontinue (terminate) connectivity maintenance procedures, the fixed 
station shall: 

a. Cancel the connectivity timer. 

b. Reset the connectivity counter to zero. 

c. Cancel any pending retransmission procedures. 

d. Discontinue the sending of any and all RTP packets via the Voice 
Conveyance Service. 

3. Upon receipt of a Heartbeat message, in the CS Not Connected state, the 
fixed station shall silently discard the message. 

4. Upon receipt of a FSCJHEARTBEAT in the CS Connected state, the fixed 
station shall: 

a. If and only if the IP address and port of the message match those from 
the most recent successful FSC_CONNECT message, the fixed 
station shall: 

i. Reset a connectivity counter to zero. 

ii. Start a connectivity timer with the value FSConnectivityTxTimer. 

b. Otherwise, the fixed station shall silently discard the 
FSC_HEARTBEAT message. 

5. Upon expiration of the connectivity timer, the fixed station shall: 

a. Increment the connectivity counter. 

b. If the connectivity counter is equal to FSConnectivityLossLimit, the 
connection has been lost. The fixed station shall revert to the CS Not 
Connected state. 

c. Otherwise, the fixed station shall transmit a heartbeat to its host. 
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8.3.2.5 Other Procedures 

The following procedures related to actions performed following the validation of a 
message as described in 8.3.2.3. Each of these procedures results in the generation 
of an FSC_ACK message. 


8.3.2.5.1 Single Block Control Message Procedure 

The following procedure applies when a host receives a valid FSC_SBC command 
from a fixed station: 

1. If the host does not support the Single Block Control message contained in 
the command: 

a. The host shall reply with FSC_ACK with the ACK/NAK code set to 
CONTROL_NAK_F_UNSUPP. 

b. Upon receiving the FSC_ACK, the fixed station shall take such steps 
as may be required by its air interface and local policy. 

2. Otherwise, the host: 

a. Shall reply with FSC_ACK with the ACK/NAK code set to 
CONTROL_ACK and shall take such actions as may be required by 
the received message and local policy. 

b. In the event that the Single Block Control (SBC) message requires a 
response, the host shall formulate a Single Block Control message 
response (recommended to be implemented in accordance with the 
requirements of TSB102.AABG (see [14])), and shall transmit an 
appropriate FSC_SBC to the fixed station. 

The following procedure applies when a fixed station receives a valid FSC_SBC 
command from its host: 

1. If the fixed station does not support the Single Block Control message 
contained in the command: 

a. The fixed station shall reply with FSC_ACK with the ACK/NAK code 
set to CONTROL_NAK_F_UNSUPP and the response data length set 
to zero. 

b. Upon receiving the FSC_ACK, the host shall take such steps as may 
be required by the host’s air interface and local policy. 

2. If the fixed station subsystem is transmitting a voice stream on the outbound 
CAI at the time that it receives the FSC_SBC from the CFSFI: 

a. The fixed station shall reply with an FSC_ACK with the ACK/NAK code 
set to CONTROL_NAK_BUSY. 

b. The fixed station should discard the FSC SBC. 
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3. Otherwise, the fixed station shall respond with FSC_ACK with the ACK/NAK 
code set to CONTROL_ACK and shall further transmit the corresponding 
conventional message via the outbound air interface. 

8.3.2.5.2 Manufacturer Extension Procedure 

Processing of the FSC_MAN_EXT shall be manufacturer specific, but shall always 
result in the generation of FSC_ACK with an ACK/NAK code of CONTROL_ACK if 
the command was successfully executed, and an ACK/NAK code with some other 
value if the command was not successfully executed. 

If a FSC_MAN_EXT is received that the receiver does not support, it shall send an 
acknowledgement with a NAK of CONTROL_NAK_M_UNSUPP and no response 
data. 

8.3.2.5.3 Channel Selection Command Procedure 

Upon receipt of a valid FSC_SEL_CHAN command, the fixed station subsystem: 

• Shall reply with FSC_ACK with an ACK/NAK code of 
CONTROL_NAK_PARMS if the Channel Number parameter is illegal. 

• Shall reply with FSC_ACK with an ACK/NAK code set to 
CONTROL_NAK_BUSY and discard the FSC_SEL_CHAN command, if the 
fixed station subsystem is currently transmitting voice. 

Otherwise, it shall set the receive channel selection as indicated by the command 
and reply with FSC_ACK with and ACK/NAK code of CONTROL_ACK. In both 
cases, the Response Data Length of FSC_ACK shall be zero. 


8.3.2.5.4 Repeat Mode Selection Procedure 

Upon receipt of a valid FSC_SEL_RPT command, the fixed station shall begin 
operating in the selected mode and reply with FSC_ACK with and ACK/NAK code of 
CONTROL_ACK. The Response Data Length of FSC_ACK shall be zero. 


8.3.2.5.5 Squelch Control Procedure 

Upon receipt of a valid Squelch Control command, the fixed station shall reply with 
FSC_ACK with an ACK/NAK code of CONTROL_NAK_PARMS if it does not support 
the selected mode in its current operating mode. Otherwise, it shall begin operating 
in the selected mode FSC_ACK with and ACK/NAK code of CONTROL_ACK. In 
both cases, the Response Data Length of FSC_ACK shall be zero. 


8.3.2.5.6 Report Selections Procedure 

Upon receipt of a valid FSC_REPORT_SEL command, the fixed station shall reply 
with FSC_ACK with an ACK/NAK code of CONTROL_ACK. The Response Data of 
the FSC ACK shall be as indicated in 8.3.1.9. 
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8.4 DFSI Voice Conveyance Service 

8.4.1 Structure of Voice Conveyance Payload 

The Voice Conveyance Payload shall consist of a payload header followed by blocks 
of data (Voice Conveyance Payload) as illustrated in Figure 24. The blocks of data 
carry P25 voice, signaling that is carried with voice on the P25 CAI and analog 
transparent audio. The Voice Conveyance Payload header shall indicate which of 
these blocks are present in the packet. 

Figure 24 - Overview of DFSI Voice Conveyance Packet 
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8.4.1.1 Voice Conveyance Payload Header 

The P25 RTP payload allows compact (often called compressed) and verbose (often 
called un-compressed) forms of the Voice Conveyance Payload header. This 
revision of the fixed station interface shall support the compact form (indicated by 
the C bit = 1, see below). Indicator bits are retained to allow for future support of the 
verbose form. 

The Voice Conveyance Payload header shall consist of a control octet which 
indicates the number of Voice Conveyance blocks and one or more octets that 
indicate the types of blocks in the remainder of the payload as illustrated in Figure 
25. 
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Figure 25 - DFSI Voice Conveyance Payload Header 
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1 st Block Type 
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8.4.1.1.1 Payload Header Control Octet. 

The payload header control octet shall contain 4 fields as illustrated in Figure 26. 

Figure 26 - Control Octet 


0 


0 

1 

2 3 4 5 6 7 

S 

C 

Block Header 
Count 


The bits of the control octet are defined as follows: 

S - Signal bit. Has no special meaning for the DFSI. Any value may be sent. 
Receivers should ignore this flag. 

C - Compact. Indicates the compact payload header. 

C =0 Shall be reserved for future use with the verbose payload 
header. 

C =1 Compact block header shall be used in this revision of the fixed 
station Interface. 

Block Header Count - The number of Block Types header bytes following the 
control octet. This is also the number of payloads in the packet. 
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8.4.1.1.2 Voice Block Types 

Following the payload header control octet there are one or more Block type octets. 
The block types are followed by the block payloads. Figure 27 illustrates the 
structure of payload header and information blocks. 

Figure 27 - Structure of Payload Header and Information Blocks 
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The block type octet is split into two fields, illustrated in Figure 28. 

Figure 28 - Format of Block Type Field 


0 

0 1 2 3 4 5 6 7 


E Block PT 


E Indicates whether Block PT is a standard IANA defined RTP payload 
type or a P25 specific payload. 

E = 0 Shall mean that block PT indicates a standard IANA defined RTP 
payload is encapsulated in this Voice Conveyance Block Payload. 
The standard IANA defined RTP payload types supported in this 
revision of the fixed station interface shall be: 0, p law PCM audio. 
This encoding scheme is described in RFC 3551 (see [18]). The 
guidelines described in reference [18] are followed except that the 
payload is encapsulated in a Voice Conveyance Block Payload. 

E = 1 Shall mean that the block PT indicates a block type specific to 
the voice conveyance payload. The block types supported by this 
version of the DFSI are defined in 8.3.2. 


51 











TIA-102.BAHA 


Block PT indicates the type of the corresponding payload. For E=0, Block PT 
shall be 0, indicating p law PCM audio. For E=1, Block PT may take on the 
following values: 

0 - CAI Voice 

6 - Voice Header Part 1 

7 - Voice Header Part 2 

9 - Start of Stream 

10 - End of Stream 

12 - Voter Report 

13 - Voter Control 

14 - TX Key Acknowledge 
63-127 - Manufacturer Specific 

In addition, the following values are reserved. 

1 - Reserved for Packet Type 

2 - Reserved for Link Control Word 

3 - Reserved for Encryption Sync 

4 - Reserved for Low Speed Data 

5 - Reserved for Header Word 

8 - Reserved 

11 - Reserved for PTT Control Word 
15-62 - Reserved for future expansion 


The details of the P25 specific RTP Payloads are defined in 8.4.2 


8.4.2 Voice Conveyance RTP Payload, Block PTs 

In addition to the IETF defined Block PT type 0, p law PCM audio (used with E=0), 
several more block types are needed by a dispatch radio system. These are 
indicated with an E bit of 1. This provides for up to 128 additional Block Payload 
Types (Block PTs). Only a few Block PTs, described in the next sections, are 
required for the DFSI. 

All of the following specific types are designated as the Block PT. Designation 
excludes the E bit. 

The value of the block type will be equal to 128 + Block PT. 


8.4.2.1 Block with PT= 0 - CAI Voice 

Blocks with this PT shall contain the P25 Common Air Interface (CAI) Improved 
Multiband Excitation (IMBE) voice codec data along with additional data that is 
paired with a particular voice frame on the P25 CAI (see [8]). 
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The IMBE data is divided into 8 decoded message vectors (U0-U7) as described in 
Tl A/E I A-102. BABA (see [11]). The message vectors U0-U6 have been decoded 
(error correction code removed). Vector U7 is unprotected on the CAI. 

All CAI frames shall contain these 14 octets. Figure 29 illustrates the common fields 
for CAI blocks. 


Figure 29 - Common Fields for CAI Blocks 
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A frame type field indicates which frame in a P25 super frame this block carries. This 
is necessary because different pieces of additional signaling are carried with each 
frame. The frame type field is composed of a Protocol Identifier (PID) and Frame 
Type (FT). 

The first (high order) 3 bits of the field shall constitute the PID. The next 5 bits signify 
a frame type associated with that protocol identifier. For this revision of the fixed 
station interface PID = 3 shall be supported. Frame type shall have a range of 1 to 
18 decimal or 1 to 12 hexadecimal. Hence the combined octet PID/FT shall have a 
range of 61 to 73 in hexadecimal notation. 
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The composition of the blocks with each PID/FT shall be as follows in Table 7. 


Table 7 - CAI Frame Types 


Name 

PID/FT 

Description 

IMBEFRAME1 

$62 

IMBE Voice 1 

IMBEFRAME2 

$63 

IMBE Voice 2 

IMBEFRAME3 

$64 

IMBE Voice 3 + Link Control 

IMBEFRAME4 

$65 

IMBE Voice 4 + Link Control 

IMBEFRAME5 

$66 

IMBE Voice 5 + Link Control 

IMBEFRAME6 

$67 

IMBE Voice 6 + Link Control 

IMBEFRAME7 

$68 

IMBE Voice 7 + Link Control 

IMBEFRAME8 

$69 

IMBE Voice 8 + Link Control 

IMBEFRAME9 

$6 A 

IMBE Voice 9 + Low Speed Data 

IMBEFRAME 10 

$6B 

IMBE Voice 10 

IMBEFRAME 11 

$6C 

IMBE Voice 11 

IMBEFRAME 12 

$6D 

IMBE Voice 12 + Encryption Sync 

IMBEFRAME 13 

$6E 

IMBE Voice 13 + Encryption Sync 

IMBEFRAME 14 

$6F 

IMBE Voice 14 + Encryption Sync 

IMBEFRAME 15 

$70 

IMBE Voice 15 + Encryption Sync 

IMBEFRAME 16 

$71 

IMBE Voice 16 + Encryption Sync 

IMBEFRAME 17 

$72 

IMBE Voice 17 + Encryption Sync 

IMBEFRAME 18 

$73 

IMBE Voice 18 + Low Speed Data 


The report count fields shall reflect the number of decoding errors detected when the 
over the air frame was recovered at a receiver and the error correcting code (Golay 
or Hamming) was decoded. These may be used for error mitigation when the voice 
is decoded. If the number of errors detected is greater than can be indicated in the 
report field, the field shall be set to the maximum value. 

Et shall be the total number of errors detected in the frame. This shall be the 
parameter e T described by equation 95 in TIA/EIA-102.BABA (see 
[11]) and limited to a maximum value of 7. 

Er is a scaled version of s R described in equation 96 of reference [11], Er 
shall be equal to 400 x a R rounded down to the nearest integer and 
limited to a maximum of 7. 

M is the mute frame flag. When M is set to 1 and L set to 1 the frame should 
be muted. When M is reset to 0 and L set to 1 the previous frame 
should be repeated. The criteria for deciding that a frame should be 
muted are described in section 7.8 of reference [11], 

L is the lost frame flag. When L is set to 1, it indicates a bad frame that should 
be muted or the previous frame repeated. The criteria for deciding that 
a frame should be muted or repeated are described in sections 7.7 and 
7.8 of reference [11], 
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E4 shall be the number of errors detected in vector U4, limited to a maximum 
of 1. 

El shall be the number of errors detected in vector U1, limited to a maximum 
of 7. 

SF indicates a 2-bit free running super frame counter that is incremented on 
the first frame of each super frame. For this issue of the fixed station 
interface, this behavior is to maintain consistency with the ISSI. 

B indicates the busy status field as defined in TIA/EIA-102.BAAA (see [8]). 

In addition to the above 14 octets present on all IMBE frames, each of the following 
frame types specifies zero or more additional bytes that are appended to the end of 
the frame. 


8.4.2.1.1 CAI Frames 1, 2, 10, and 11. 

CAI Frames 1,2, 10 and 11 have frame type fields $62, $63, $6B, $6C respectively. 
These frames shall contain only the basic14 octets with no additional data. Figure 30 
illustrates the format for CAI Frames 1,2, 10, and 11. 


Figure 30 - Format for CAI Frames 1,2,10, and 11 
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8.4.2.1.2 CAI Frames 3 to 8 with Link Control Data 

CAI frames 3 to 8 have frame type fields $64 - $69 respectively. They include an 
additional 4 bytes to carry Link Control data. 

The Link Control field of a block shall carry four of the 24 RS encoded 6-bit link 
control code words as described in section 5.5 of TIA/EIA-102.BAAA (see [8]). Refer 
to TIA-102.AABF-A (see [10]) for detailed discussions of Link Control definitions. 

The link control field shall contain code words: 

0,1,2, and 3 for CAI frame 3; 

4, 5, 6, and 7 for CAI frame 4; 

8, 9, 10, and 11 for CAI frame 5; 

12, 13, 14, and 15 for CAI frame 6; 

16, 17, 18, and 19 for CAI frame 7; or 
20, 21,2,2 and 23 for CAI frame 8. 

The STATUS field is defined as follows: 

STATUS = ST3 * 3 3 + ST2 * 3 2 + ST1 * 3 1 + STO * 3° 


Where 

STn=error status of LCn 
STn=0 means no errors 
STn=1 means 1 error 
STn=2 means erasure 

Again, the “R” bits are reserved. Figure 31 illustrates the CAI block with a link control 
word field. 


Figure 31 - CAI block with Link Control Word Field 
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8.4.2.1.3 CAi Frame 9 and 18 with Low Speed Data. 

Frames 9 and 18 have Frame Type fields of $6A and $73 respectively. This field of a 
block shall contain two octets of low speed data, as described in section 5.6 of 
TIA/EIA-102.BAAA (see [8]), either: 

Octets 0 and 1 (CAI frame 9) or 
Octets 2 and 3 (CAI frame 18). 

The low speed data is accompanied by two 2-bit status words to indicate the number 
of errors decoded at the receiver. The binary values of this field are defined as 
follows: 

00 = no errors 

01 = 1 error 

02 = 2 errors 

03 = erasure - indicates that the decoder detected an uncorrectable 
combinations of errors in the code word. 

Si - Status Bit SO (CAI Frame 9), Status Bit S2 (CAI Frame 18) 

Sj - Status Bit SI (CAI Frame 9), Status Bit S3 (CAI Frame 18) 

Figure 32 illustrates the CAI block with a low speed data field. 

Figure 32 - CAI Block with a Low Speed Data Field 
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8.4.2.1.4 CAI Frames 12 to 17 with Encryption Sync 

Frames 12 to 17 have Frame Type fields of $6D to $72 respectively and carry four of 
the 24 RS encoded 6-bit encryption sync code words described in section 5.4 of 
TIA/EIA-102.BAAA (see [8]). The encryption sync field contains code words: 

0,1,2 and 3 for Frame 12; 

4, 5, 6 and 7 for Frame 13; 

8, 9, 10 and 11 for Frame 14; 

12, 13, 14 and 15 for Frame 15; 

16, 17, 18 and 19 for Frame 16; or 
20, 21, 22 and 23 for Frame 17. 

The 7-bit status field indicates the number of bit errors detected when the over the 
air Hamming code was decoded. 

The STATUS field is defined as follows: 

STATUS = ST3 * 3 3 + ST2 * 3 2 + ST1 * 3 1 + STO * 3° 

Where: 

STn=error status of ESn 
STn=0 means no errors 
STn=1 means 1 error 
STn=2 means erasure 

Figure 33 illustrates the CAI block with encryption sync field. 

Figure 33 - CAI Blocks with Encryption Sync Field 
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8.4.2.2 Block with PT = 1 - Packet Type 

Blocks of this type are not supported for this version of the fixed station interface. 

8.4.2.3 Block with PT = 2 - Link control word 

Blocks of this type are not supported for this version of the fixed station interface. 
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8.4.2.4 Block with PT = 3 - Encryption sync word 

Blocks of this type are not supported for this version of the fixed station interface. 

8.4.2.5 Block with PT = 4 - Low speed data 

Blocks of this type are not supported for this version of the fixed station interface. 

8.4.2.6 Block with PT = 5 - Header word 

Blocks of this type are not supported for this version of the fixed station interface. 

8.4.2.7 Block with PT = 6 - Voice Header Part 1 

Blocks of this type are sent at the start of a P25 voice stream. The contents shall be 
the information bits of the first 18 Header Data Unit Golay code words on the air 
interface. 

If the fixed station subsystem receives a P25 voice stream from the air interface 
without a header data unit (such as due to an RF fade) it may send this voice stream 
on the fixed station interface with out any voice header blocks. In this case the 
receiver of the DFSI voice stream may extract the header data from the link control 
and encryption sync words carried with the P25 voice stream. 

The block also contains 3-bit status fields for each of the code words to indicate the 
number of errors detected in decoding the Golay code. The 3-bit status fields are 
split, with the two most significant bits sharing the same byte as the associated code 
word and the least significant bit lumped into one of three other bytes with the LSB's 
from other code words. 

Fixed stations shall transmit within a Header code data unit on the air interface, the 
contents of a block of this type received on the DFSI. 

For more details of the header fields see TIA/EIA-102.BAAA (see [8]). 

The frame type for a block with this PT shall be $60. 
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Figure 34 illustrates the first part of the CAI voice header. 

Figure 34 - CAI Voice Header Part 1 
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8.4.2.8 Block with PT = 7 - Voice Header Part 2 

Blocks of this type are sent following the Block with PT = 6 - Voice Header Part 1. 
The contents shall be the information bits of the last 18 Header Data Unit Golay 
code words on the air interface. 

If the fixed station subsystem receives a P25 voice stream from the air interface 
without a header data unit (such as due to an RF fade) it may send this voice stream 
on the fixed station interface with out any voice header blocks. In this case the 
receiver of the FSI voice stream may extract the header data from the link control 
and encryption sync words carried with the P25 voice stream. It also contains 3-bit 
status fields for each of the code words to indicate the number of errors detected in 
decoding the Golay code. The 3-bit status fields are split, with the two most 
significant bits sharing the same byte as the associated code word and the least 
significant bit lumped into one of three other bytes with the LSB's from other code 
words. 

Fixed stations shall transmit within a Header code data unit on the air interface, the 
contents of a block of this type received on the fixed station interface. 

For more details of the header fields see TIA/EIA-102.BAAA (see [8]). 

The frame type for blocks with this PT shall be $61. 

Figure 35 illustrates the second part of the CAI voice header. 
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Figure 35 - CAI Voice Header Part 2 
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8.4.2.9 Block with PT = 9 - Start of Stream 

Fixed stations shall be capable of sending blocks of this type on the fixed station 
interface. It shall contain the NID of the first data unit that the fixed station receives 
in a stream. 

This block explicitly identifies the start of a stream. 

NID-Comprised of the NAC and DU ID. See TI A/E I A-102. BAAA (see [8]) for 
details. 

Err Cnt - 4-bit count of the number of errors detected in the NID. 

Figure 36 illustrates the start of stream block. 

Figure 36 - Start of Stream Block 
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8.4.2.10 Block with PT = 10 - End of Stream 

Fixed stations shall send a block of this type when they detect the end of a voice 
stream on the air interface. This packet type explicitly identifies the end of a stream. 
No data apart from the RTP block header is defined. 


8.4.2.11 Block with PT = 11 - PTT Control Word 

Blocks of this type are not supported for this version of the fixed station interface. 
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8.4.2.12 Block with PT = 12 - Voter Report 

This block is provided so that the fixed station subsystem can report the receiver 
status for each receiver. If multiple receivers are reported, multiple blocks may be 
included in one packet. Voter Reports are only sent on the inbound DFSI. Figure 37 
illustrates the voter report block. 

Figure 37 - Voter Report Block 
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Receiver number 0 is reserved for use in Block with PT = 13 - Voter Control. 
Receiver numbers 1 to 255 indicate the receiver that the report is for. Mapping of the 
receiver number to receiver names and physical location are determined by 
equipment configuration parameters. 

D indicates if this receiver is Disabled. 

D=0 means that the receiver is not disabled. 

D=1 means that this receiver is inhibited because of a DISABLE command for 
this number (or all receivers) or a SELECT command for another receiver 
number. 

Table 8 shows receiver status voter report code meanings. . 

Table 8 - Receiver Status Voter Report Codes 


Code 

Mnemonic 

Meaning 

0 

NO_SIGNAL 

No usable signal is being received by this 
receiver. 

1 

SELECTED 

This receiver is currently selected. The audio 
being sent originates from this receiver. 

2 

GOOD_P25 

A P25 signal with the correct NAC being received 
by this receiver. This receiver is not currently 
selected by the voter. 

3 

GOOD_FM 

An FM signal with the correct sub-audible signal (if 
applicable) is being received by this receiver. This 
receiver is not currently selected. 

4 

BAD_P25 

A P25 signal is being received by this receiver but 
the NAC does not match the desired NAC. 


62 






TIA-102.BAHA 


Table 8 - Receiver Status Voter Report Codes (concluded) 


Code 

Mnemonic 

Meaning 

5 

BAD_FM 

An analog FM signal is being received by this 
receiver but the desired sub-audible signal has not 
been detected. 

6 

NOT EQUIPPED 

No receiver is equipped for this number. 

7 

FAILED 

The receiver with this number has failed. 


8.4.2.13 Block with PT = 13 - Voter Control 

Voter control blocks are sent on the outbound fixed station interface. Figure 38 
illustrates the voter control block. 

Figure 38 - Voter Control Block 
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Receiver number = 0 indicates that this command applies to all receivers. Receiver 
numbers 1 to 255 indicate the receiver that this command relates to. The receiver 
number used here shall be same as the receiver number used for the same physical 
receiver in Block with PT = 12 - Voter Report. 

Table 9 shows the meanings of the voter control command. 

Table 9 - Voter Control Command 


Code 

Mnemonic 

Meaning 

0 

REPORT 

Send the status of this receiver now. 

1 

NORMAL 

Forward speech from the receiver that has the best 
signal. This command cancels any SELECT or 
DISABLE command. Receiver number is not 
relevant to this command. Receiver number = 0 
should be used with this command. 

2 

SELECT 

Forward this receiver’s speech regardless of how 
good the signal is. 

This command disables all other receivers. 

This command can not be used with Receiver 
Number = 0. 

3 

DISABLE 

Don't forward this receiver’s speech regardless of 
how good it is. 
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8.4.2.14 Block with PT = 14 Tx Key Acknowledge 

This is sent on the inbound path indicating to the CSFH that the fixed station has 
started transmitting on the CAI. No data apart from the RTP block header is defined. 


8.4.2.15 Block PT = 63 to 127 - Manufacturer specific data 

These packet types are provided so individual manufacturers can carry additional 
proprietary data within a stream. Equipment conforming to this standard may include 
such blocks however they must follow any standard blocks which are sent in the 
same packet. 

Equipment conforming to this standard shall ignore blocks of these types whose 
MFID they do not understand. However equipment conforming to this standard shall 
appropriately process any standard blocks which precede a manufacturer specific 
block in the same packet. 

The length field specifies the number of octets in this block following the length field. 
Beyond the mandatory P25 manufacturer’s identification (MFID) field and the length, 
the format of the internals of this packet are left open for any use. Manufacturers are 
encouraged to propose packet types, which may be of general use, to the TIA for 
inclusion in this profile. Figure 39 illustrates the format for manufacturer 
customizations. 


Figure 39 - Format for Manufacturer Customizations 
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8.4.3 Voice Conveyance Service Procedures 

8.4.3.1 Connection of the Voice Conveyance Service. 

8.4.3.1.1 Not Connected State 

When the control service for a CFSH - Fixed Station Subsystem pair is in the not- 
connected state the voice conveyance service for that CFSH - Fixed Station 
Subsystem pair shall also be in the not connected state. 

No voice conveyance packets are exchanged between a CFSH - Fixed Station 
Subsystem pair when they are in the not connected state. 

The process of entering and leaving the connected state is described in 8.3. 
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8.4.3.1.2 Connected State 

When the control service for a CFSH - Fixed Station Subsystem pair is in the 
connected state the voice conveyance service for that pair shall also be in the 
connected state. 

The process of entering and leaving the connected state is described in 8.3. 

When a CFSH - Fixed Station Subsystem pair are in the connected state they shall 
exchange voice conveyance packets according to the following procedures 
described in 8.4.3.2 through 8.4.3.7. 

The setting of IP addresses, SSRC and UDP port number are described in 8.3. 


8.4.3.2 Voting Control 

The fixed station subsystem shall send an update of its state whenever its state 
changes. It shall send a report of its new state when it receives a voter control 
command. The fixed station subsystem shall also send periodic reports of its status. 
This allows for any reports which were missed when it changed state. 

The Fixed Station Subsystem shall send a Block with PT = 12 - Voter Report for 
each receiver in the subsystem at least as often as specified by the vote report 
interval configuration parameter. 

The fixed station subsystem shall send a Block with PT = 12 - Voter Report for the 
specified receiver (or all receivers if receiver number = 0) when it receives a Block 
with PT = 13 - Voter Control. 

The fixed station subsystem shall send a Block with PT = 12 - Voter Report when 
the indicated receiver's status changes. 

The fixed station subsystem shall begin forwarding voice traffic from the receiver 
with the best signal when it receives a Block with PT = 13 - Voter Control with the 
command NORMAL. The method for determining the best signal is up to the 
manufacturer of the comparator / voter. 

The fixed station subsystem shall forward all voice traffic from the specified receiver 
and stop forwarding voice traffic from all other receivers when it receives a Block 
with PT = 13 - Voter Control with command SELECT. 

The fixed station subsystem shall stop forwarding voice packets from the specified 
receiver (or all receivers if the receiver number = 0) when it receives a 
Block with PT = 13 - Voter Control with command DISABLE. 

If the fixed station subsystem receives a Block with PT = 13 - Voter Control 
specifying a receiver number that does not exist for that fixed station subsystem it 
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shall send a Block with PT = 12 - Voter Report specifying that receiver number with 
status NOT_EQUIPPED, unless the specified receiver number was 0. 


8.4.3.3 Starting Voice Transfer 
8.4.3.3.1 Start of Stream 

When initiation of voice transfer across the CAI is required, a packet shall be sent 
containing a Block with PT = 9 - Start of Stream. 

If the voice transfer is an analog transparent stream this packet should also contain 
a block of type 0 as described in 8.4.3.6, Transport of Analog Transparent Voice. 

On the outbound path, each packet sent following the start of stream shall include a 
Block with PT = 9 - Start of Stream until a Block with PT = 14 Tx Key Acknowledge 
has been received on the inbound path. 

These packets may also include voice stream blocks even though a Block with PT = 
14 Tx Key Acknowledge has not yet been received. The receipt of the Block with PT 
= 14 Tx Key Acknowledge should not delay the transmission of speech. The Block 
with PT = 14 Tx Key Acknowledge is provided so that the human operator of a 
console may be given an indication that the fixed station was successfully keyed. 


8.4.3.3.1.1 NAC 

If the CFSH intends the fixed station subsystem to use a locally configured NAC on 
the outbound CAI, the CFSH shall set the value of NAC to $F7E. 

If the CFSH intends the fixed station subsystem to use a specific NAC on the 
outbound air interface, the specific NAC shall be sent in the packet. This specific 
NAC shall not be $F7E or $F7F. 

If the NAC in the start of stream message on the outbound DFSI is not $F7E the 
fixed station shall use this NAC on the outbound CAI. 

If the NAC in the start of stream message on the outbound DFSI is $F7E the fixed 
station shall use a locally configured NAC on the outbound CAI. 

On the inbound fixed station interface the fixed station subsystem shall insert the 
NAC received on the inbound CAI. 


8.4.3.3.1.2DUID 

The DU ID shall be either %0000 (header data unit), %0101 (LDU1) or % 1010 
(LDU2). 
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If the stream starts with a Block with PT = 5 - Header word the DU ID shall be 
%0000 (header data unit). 

DUID %0101 (LDU1) or % 1010 (LDU2) may be sent when the header of a voice 
stream received on the CAI is missed and the LDU is the first decodable data has 
been received. 


8.4.3.3.1.3Err Cnt 

On the in bound fixed station interface the “Err Cnt” field of a Block with PT = 9 - 
Start of Stream, shall be the number of errors a detected in the NID received on the 
CAI. 


8.4.3.3.1.4Super Frame Counter 

P25 voice streams include a super frame count. Senders shall reset their super 
frame counter to zero when they start a stream. 


8.4.3.3.2 Acknowledging Start of Stream 

When a fixed station subsystem receives an outbound packet containing a start of 
stream message it shall key the transmitter. When the transmitter is successfully 
keyed the fixed station subsystem shall send an inbound packet containing Block 
with PT = 14 Tx Key Acknowledge. 

Once the transmitter is successfully keyed, the fixed station subsystem shall send a 
Block with PT = 14 Tx Key Acknowledge in response to every start of stream that it 
receives. 

The CFSH sends outbound DFSI packets across the CAI. 


8.4.3.3.3 Intercom Traffic 

If an outbound voice stream starts without a Block with PT = 9 - Start of Stream the 
fixed station subsystem shall not key its transmitter but route the audio to its 
intercom facility if equipped. 

Audio from the fixed stations intercom facility, if equipped, is routed to the inbound 
path of the DFSI. The inbound voice stream audio from the intercom is differentiated 
from the audio originating on the CAI since it starts without a Block with PT = 9 - 
Start of Stream. It is expected that the users talking from the fixed station will identify 
themselves verbally. Verbal identification may be supplemented by the use of 
specific talk groups or P25 source address if the option to transfer intercom traffic as 
a P25 voice stream is being used. 
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Equipment implementing the DFSI shall support the transfer of intercom audio in 
analog transparent (G.711) mode. 

As a standard option Intercom traffic may alternatively be transferred as a P25 voice 
stream. This option would require that the fixed station includes a vocoder. 


8.4.3.4 The Header Packets 

When a P25 voice stream is received from the CAI the header shall be sent on the 
DFSI as two fragments. This reduces delay since the first part of the header may be 
sent across the network before the entire header has been received on the CAI. 

DFSI equipment sending an analog transparent stream shall not send any header 
packets. DFSI equipment that missed the header on the in-bound CAI should not 
send any header packets. 


8.4.3.4.1 Sending Voice Headers on the Fixed Station Interface. 

DFSI equipment shall send the first part of the P25 header in a packet containing a 
single Block with PT = 6 - Voice Header Part 1. As soon as the remainder of the 
header is received on the CAI, equipment shall send the second part of the header 
in a packet containing a single Block with PT = 7 - Voice Header Part 2. 

Figure 40 illustrates the start of stream message sequence for outbound voice, and 
Figure 41 illustrates the start of stream message sequence with the first ACK lost. 

Figure 40 - Start of Stream Message Sequence - Outbound Voice 

CFSH Fixed Station Sub System 
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Figure 41 - Start of Stream with the First ACK Lost 
CFSH Fixed Station Sub System 



8.4.3.5 Transferring Voice 

8.4.3.5.1 P25 IMBE Voice 

Each frame of P25 voice to be sent on the fixed station shall be encapsulated as 
described in 8.4.2.1 Block with PT= 0 - CAI Voice. This shall be combined with any 
other blocks that need to be sent at the same time in an RTP packet. Each RTP 
packet may contain 1, 2, or 3 Block with PT= 0 - CAI Voice. 

On the inbound path error correction is performed on the voice frames received from 
the CAI and the error counts are added to the error control fields of the block. 


8.4.3.5.2 Super Frame Counter 

Before sending a CAI frame type $62 (IMBE voice 1) senders shall increment their 
super frame counter by 1. Senders shall insert the current value of their super frame 
counter in the SF field. 


8.4.3.5.3 B Status Field 

The Fixed station subsystem shall set the status symbols transmitted on the CAI to 
match the B field of the last status symbol received on the inbound CAI. The CFSH 
shall set the B field in the Block with PT= 0 - CAI Voice packets to match the status 
symbol desired on the outbound CAI. 


8.4.3.6 Transport of Analog Transparent Voice 

Analog transparent voice is a voice band signal typically sent to or from an analog 
FM RF transmitter or receiver. The fixed station is transparent to this base band 
signal and does not attempt to extract any meaning from it. In the receive direction 
the signal is demodulated, sampled and encoded. In the transmit direction it is 
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decoded and modulated. Often this may be simply voice but it may include in band 
signaling between the analog subscriber units and the CSFH. 

When in analog transparent mode DFSI equipment shall encode the analog audio 
signal using the p law PCM scheme described in ITU-T Recommendation G.711 
(see [12]). Every 20 ms 160 PCM samples are assembled into a analog transparent 
voice packet consisting of a block of type 0 E=0 PCMU. The format of this block is 
described in RFC 3551 (see [18]). 

Figure 42 shows an example of the packet with analog transparent data block type. 

Figure 42 - Packet with Analog Transparent Data 
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8.4.3.7 Terminating a Voice Stream 

When equipment implementing the DFSI determines that a voice stream has ended 
it shall send four packets with a single Block with PT = 10 - End of Stream spaced 
100 ms apart. If a new voice stream starts before all the end of stream packets have 
been sent, the remaining end of stream packets need not be sent and the new voice 
stream may be started immediately. 

When a fixed station receives an end of stream packet it should de-key its 
transmitter. If a fixed station receives no voice packets for longer than a 
manufacturer specified timeout (typically 4 seconds) it should de-key its transmitter. 

Figure 43 illustrates the end-of-stream process and Figure 44 illustrates the end-of- 
stream time-out. 
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Figure 43 - End of Stream 
CFSH Fixed Station Sub System 



Figure 44 - End of Stream Time Out 
CFSH Fixed Station Sub System 
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